1. Field
This description relates in general to distributed computing systems, and more particularly, to a method, system and computer program product for managing a tertiary storage unit in bidirectional data copying in a distributed computing system.
2. Description of Related Art
Data backup systems can provide continuous availability of production data in the event of a sudden catastrophic failure at a single point in time or data loss over a period of time. In one such disaster recovery system, production data is replicated from a local site to a remote which may be separated geographically by several miles from the local site. Such dual, mirror or shadow copies are typically made in a secondary storage device at the remote site, as the application system is writing new data to a primary storage device usually located at the local site. Different data replication technologies may be used for maintaining remote copies of data at a secondary site, such as International Business Machine Corporation's (“IBM”) Metro Mirror Peer to Peer Remote Copy (PPRC), Extended Remote Copy (XRC), Coupled XRC (CXRC), Global Copy, and Global Mirror Copy.
In data mirroring systems, data is typically maintained in volume pairs, comprising a primary volume in a primary storage device and a corresponding secondary volume in a secondary storage device that includes an identical copy of the data maintained in the primary volume. The primary and secondary volumes are identified by a copy relationship in which the data of the primary volume, also referred to as the source volume, is copied to the secondary volume, also referred to as the target volume. Primary and secondary storage controllers may be used to control access to the primary and secondary storage devices.
Tivoli Productivity Center for Replication is an example of an application that customers may use to manage planned and unplanned outages. The Tivoli Productivity Center for Replication application can detect failures at the primary storage system which may be at a local site, for example. Such failures may include a problem writing or accessing primary storage volumes at the local site. When the Tivoli Productivity Center for Replication recovery application detects that a failure has occurred, it can invoke a multi-storage volume swapping function, an example of which is the IBM HyperSwap® function. This function may be used to automatically swap processing for all volumes in the mirrored configuration from the local site to the remote site. As a consequence of the swap, the storage volumes at the remote site which were originally configured as the secondary volumes of the original copy relationship, are reconfigured as the primary volumes of a new copy relationship. Similarly, the storage volumes at the local site which were originally configured as the primary volumes of the original copy relationship, may be reconfigured as the secondary volumes of the new copy relationship, once the volumes at the local site are operational again.
In some instances, it may be appropriate to copy a volume such as a secondary volume to a third volume (a tertiary volume). Thus, updates written to the primary volume, are mirrored to the secondary volume, and from the secondary volume to the tertiary volume, in a cascade arrangement. In this manner, the primary volume is a source volume to its target volume, the secondary volume, and the secondary volume is in turn a source volume to its target volume, the tertiary volume.
Should the tertiary volume lose data consistency with respect to the primary and secondary volumes, updates to the secondary volume may be suspended while the secondary volume and the tertiary volume are resynchronized using appropriate bitmaps. Bit maps may be used to map tracks of the tertiary storage volume which are out of sync with the corresponding tracks of the secondary volume, its source volume. Tracks which are out of synch may be resynchronized with a copy operation, copying data from the source track of the secondary volume to the out of sync target track of the tertiary volume.
Once the secondary volume and the tertiary volume have been resynchronized to contain the same data (often referred to as achieving “full duplex” status, updating of the secondary volume is resumed and the primary and secondary volumes may also be resynchronized. Any updates mirrored to the secondary volume are mirrored by the cascade to the tertiary volume. In this manner, the tertiary volume may be resynchronized to both the secondary and primary volumes.
Some storage mirroring systems permit a source volume to have more than one target volume. Thus, the secondary volume may, for example, have two target volumes, the tertiary volume and a fourth volume, a quaternary volume. Accordingly, updates written to the secondary volume may be mirrored to both the tertiary volume and the quaternary volume in a multi-target mirroring operation. In such an arrangement, the mirroring operation from the secondary volume to the tertiary volume occurs in parallel with the mirroring operation from the secondary volume to the quaternary volume. As a result, the data updates to the secondary volume are written in parallel to the tertiary volume and the quaternary volume, rather than in a cascade from the secondary volume to the tertiary volume and from the tertiary volume to the quaternary volume.